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ABSTRACT 


This  is  the  final  report  for  the  project  entitled  “Optimally  Locating  BETSS-C 
Surveillance  Assets”  sponsored  by  the  Joint  Improvised  Explosive  Device  Defeat 
Organization.  The  research  has  focused  on  developing  optimization  models  for  optimal 
placement  of  cameras  and  tower-mounted  surveillance  systems  such  as  BETSS-C  (Base 
Expeditionary  Targeting  and  Surveillance  Systems-Combined).  These  systems  have 
proven  themselves  useful  in  detecting  improvised  explosive  devices  as  they  are  being 
emplaced,  and  in  making  certain  locations  less  desirable  for  emplacement.  We  have 
created  models  and  solution  software  that  locate  a  given  set  of  camera  towers  (also 
observation  towers  or  aerostats)  to  optimally  cover  “points  of  interest”  on  the  ground. 
Computational  results  show  that  it  is  possible  to  obtain  near-optimal  solutions  for 
problems  with  up  to  30  cameras  and  100  points  of  interest  on  a  laptop  computer  in  less 
than  one  minute. 
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A.  BACKGROUND 

In  Iraq  and  Afghanistan,  Coalition  Forces  have  found  that  camera  towers  such  as 
“GBOSS”  (Ground-Based  Operational  Surveillance  System),  BETSS-C  (Base 
Expeditionary  Targeting  and  Surveillance  Systems-Combined),  and  JLENS/RAID  PS2 
systems,  can  help  thwart  the  emplacement  of  improvised  explosive  devices  (IEDs). 
These  systems  can  also  identify  disturbances  to  which  troops  need  to  respond,  follow 
suspicious  vehicles,  and  so  on.  Their  use,  for  similar  purposes  in  the  increasingly 
complex  war  in  Afghanistan,  is  critical  to  the  security  of  U.S.  and  allied  forces,  as  well  as 
to  the  civilian  population.  No  tool  currently  exists,  however,  for  assigning  a  limited 
number  of  camera  towers  to  a  large  number  of  potential  (secure)  sites  so  as  to 
(1)  maximize  the  “value”  of  the  surveilled  “points  of  interest”  (POIs),  (2)  maximize  the 
probability  of  detecting  specific  threats,  or  (3)  maximize  the  overall  “coverage”  of 
important  sites  that  are  surveilled.  Developing  such  a  tool  is  the  purpose  of  this  study. 

The  research  focuses  on  developing,  implementing,  and  solving  a  series  of 
prototypic  mathematical  models  for  optimizing  camera-tower  placement.  We  have 
created  nonlinear  integer  optimization  models  for  this  purpose,  have  reformulated  those 
models  for  tractability,  and  are  solving  them  using  general-purpose  optimization  tools. 

B.  MATHEMATICAL  MODELS 

1.  Basic  Camera  Location  Models 

We  first  develop  the  following  nonlinear,  camera  location  (NL-CL1) 
optimization  model: 

(NL-CL1):  min  []<?,? 

^  iel  leL 

subject  to:  ^y,  <  m  , 

i 

y,  e{0,l}V/  eL , 

where  /  e  L  is  a  given  set  of  potential  camera  locations;  iel  is  a  set  of  POIs  that  need  to 
be  kept  under  surveillance;  m  is  the  number  of  camera  towers  available;  vi  is  the  “value” 
of  POI  i,  which  represents  the  damage  or  consequences  that  events  (such  as  an  IED 
emplacement)  at  that  point  would  cause;  qn  is  the  probability  of  not  detecting  an  event  at 
POI  i  from  location  /,  if  a  camera  is  placed  at  that  location;  and  the  decision  variable  y,  is 
1  if  we  locate  a  tower  at  /,  and  yl  =  0  otherwise.  Since  ]~[  q?/  is  the  probability  that  an 

leL 

event  at  POI  i  is  not  detected  by  any  of  the  installed  cameras,  NL-CL1 ’s  objective,  under 
an  assumption  of  independence,  minimizes  overall  expected  “value”  of  undetected  events 
across  POIs,  subject  to  the  limit  on  available  cameras.  Henceforth,  we  use  “expected 
‘value’  of  undetected  events”  and  “expected  damage”  interchangeably.  In  particular,  we 
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refer  to  “expected  damage  at  an  individual  POI  vi  qj' ,  and  to  “overall  expected 

IgL 

damage,” 

iel  IgL 

We  note  that  (NL-CL1)  does  assume  independence  of  detections  between  events 
at  a  given  POI,  and  requires  some  user  inputs  that  may  not  be  immediately  available, 
namely  v;  and  qu .  It  may  be  necessary  to  use  subjective  estimates  if  these  data  are 
unavailable.  We  believe  that  the  model’s  solution  is  likely  to  provide  useful  insight  even 
when  using  subjective  input,  however. 

We  also  note  that  the  notation  in  the  model  hides  some  of  the  practical  aspects  of 
an  implementation.  Suppose,  for  instance,  that  there  is  no  line  of  sight  between  potential 
camera  location  l  and  POI  i .  In  this  case,  qu  =  1 ,  and  the  model  is  correct.  However, 

our  implementation  would  not  even  create  the  corresponding  tenn  in  the  objective 
function. 

A  second  model,  NL-CL2,  seeks  to  minimize  the  maximum  expected  damage  at 
any  POI,  i.e.,  the  worst-case  damage  among  all  POIs.  This  second  model  is: 

(NL-CL2)  min  z 

y»z 

subject  to:  I  y,  ^  rn , 

/ 

IgL 

y,  e  {0,1}  V/  e  L  , 

where  the  new  set  of  constraints  ensures  that  z  (the  objective  value  sought)  takes  the 
maximum,  among  all  POIs,  of  the  expected  damages  at  each  individual  POI.  It  is 
important  to  note  that  in  this  model  we  may  minimize  Z  =  log  z  without  affecting  the 
outcome.  Also,  since 

f  \ 

log  z  >  log  vi rR  I  V/  =>  Z  ^  lo§( )  +  X  (lo§  9a )y,  Vi  , 

V  l&L  )  IgL 

NL-CL2  can  be  restated  as  this  mixed-integer  program: 

(MI-CL2)  min  Z 

subject  to:  I  y,  ^  rn , 

l 

Z  >  log(vf)  +  X(log  9u)y,  Vi  , 

IgL 

y,  e  {0,1}  v/  g  l  . 

Unfortunately,  the  same  type  of  simplification  is  not  possible  for  NL-CL1:  The 
logarithm  function  cannot  be  used  to  decompose  that  model’s  objective  function 
2>,II  ql‘  into  a  linear  expression  of  the  j’-variablcs.  Although  we  may  expect  a  strong 

IgI  IgL 
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correlation  between  the  optimization  of  log  z».n  qf  and  that  of  2>,  log  n % 


V  iel  leL  J  iel  \  leL  J 

in  many  practical  instances,  no  guarantee  of  equivalence  exists,  and  bounding  the  error  in 
the  approximation  appears  to  be  a  difficult  task. 


2.  Converting  the  Basic  Model  into  a  Network-Flow-Based  Model 

This  section  shows  how  to  convert  NL-CL1  into  a  mixed-integer  linear  program 
that  has  an  underlying  network-flow  structure. 

We  use  the  concept  of  a  generalized  flow  (see  Ahuja  et  ah,  1993,  pp.  566-572). 
Specifically,  for  each  POI  z,  we  create  a  network  whose  nodes  correspond  to  locations 
that  could  detect  an  event  should  we  install  a  camera  at  those  locations,  that  is, 

Lt  =  {/  e  L  |  qn  <  1}  .  For  notational  simplicity,  assume  L  is  ordered  and  denote  its  first 

element  as  If ,  its  last  element  as  if ,  and  the  predecessor  to  a  given  Zei.  ( /  ^  If )  as  If . 


In  our  network  model  for  POI  i,  each  node  /  e  Lt  is  connected  to  the  next  location 
node  by  two  arcs:  The  flow  on  the  first  arc  (denoted  xu)  represents  the  probability  that 
cameras  up  to  that  node  have  not  detected  the  event,  given  that  no  camera  is  installed  at 
the  location.  The  flow  on  the  second  arc  (denoted  xf )  represents  the  same  concept,  but 
applies  when  a  camera  is  installed  at  the  node.  That  is,  when  xf  >  0  ,  part  of  the  flow 

going  into  node  I  (probability  of  non-detection  up  to  that  point)  will  be  lost  in  the 
transition  (flow)  to  the  next  location.  The  overall  probability  of  non-detection, 
a  =  n  qf  ,  is  the  flow  into  a  fictitious  node  connected  to  the  last  node  if . 

IeL 

The  mixed-integer  network  model,  MIN-CL1,  which  is  equivalent  to  NL-CL1, 
may  be  stated  as  follows: 

(MIN-CL1)  min  £>,0, 
y,x,Q 

subject  to:  x.  /F  +  xfr  =1  Vz , 

xu  +  xf  =  X  P  +  q  p  xf  p  Vz,  V/  e  Lt  \  {if }  , 

i,iil  i,iji  i,iji 

Q‘  =  xit+Vi,txU  v/’ 

0<x,7<l -y,  Vz,V/eZ,., 

0  <xf<y,  Vz,  V/  e  L, 

l 

y,  e  {0,1  }V/eZ  . 
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MIN-CL1  above  (like  the  original  NL-CL1)  allows  each  location  with  a  camera  to 
surveil  all  POIs  {i  eP  \  qu  <  1}  with  a  constant  probability  of  detection.  This  assumption 

is,  in  most  cases,  optimistic,  because  a  camera  needs  time  to  rotate,  zoom  in  and  out,  and 
focus  on  each  of  the  POIs,  and  personnel  are  needed  to  monitor  the  camera  images  from 
each  POI.  This  research  does  not  address  the  problem  of  incorporating  a  decrease  in 
detection  probability  for  a  camera  surveilling  multiple  POIs,  or  the  inherent  details  about 
frequency  of  rotation  between  surveilled  POIs,  etc.  The  work  of  our  colleagues  Burton  et 
al.  (2008)  may  apply  here  to  future  extensions,  however.  That  work  determines  the 
proportion  of  time  that  a  single  camera  should  dedicate  to  surveilling  POI  z,  assuming 
events  of  interest  occur  according  to  a  Poisson  process  with  a  location-dependent  rate 
(and  are  independent  of  events  at  other  POIs),  and  that  detection  times  at  each  location 
are  exponentially  distributed. 

To  make  our  approach  more  realistic,  we  incorporate  a  parameter,  k,  denoting  the 
maximum  number  of  sites  that  any  one  camera  may  surveil  simultaneously.  In  this  case, 
additional  variables  v,f  must  control  whether  or  not  a  camera  installed  at  location  I  will 

be  dedicated  to  surveil  POI  z.  This  can  be  accommodated  in  the  existing  models 
as  follows: 

Add  the  following  constraint  to  both  MIN-CL1  and  MI-CL2: 

Zki/  -^Tz 

i 

•  Replace  the  following  constraints  in  MIN-CL1: 

0  <  xa  <  1  -  yl  Vi,VI  e  Lt  and 

Vi, VI  e  Z. , 


with  these  new  constraints: 

0  <  xa  <  1  -  yl  Vz,  V/  e  L.  and 

0  <xl,<yl,  Vi,  VI  e  Lt . 

2 

•  Replace  the  following  constraints  in  MI-CL": 

Z  >  log(v,.)  +  £(log qil)yl  Vi 

leL 

with  this  new  constraint: 
z  >  iog(v,.)  +  Z(lo§ qu)ystt  vi  ■ 
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C.  COMPUTATIONAL  IMPLEMENTATION 

1.  Optimization  Models 

We  have  implemented  the  NL-CL1  in  GAMS  (GAMS,  2010),  and  have  solved  a 
number  of  randomly  generated  instances  using  GAMS/CONOPT  (GAMS/CONOPT, 
2010)  for  benchmarking  purposes. 

12 

For  the  mixed-integer  models,  MIN-CL  and  MI-CL",  we  have  used  the 
Xpress-MP  (FICO,  2010)  development  environment,  and  have  solved  them  with  the 
Xpress-MP  and/or  CPLEX  (IBM,  2010)  optimization  engines.  The  remainder  of  the 
document  refers  to  this  implementation. 

2.  Database 

The  supporting  database  for  our  tool  is  implemented  in  Microsoft  Access  2007 
(Microsoft,  2010).  Each  database  file  contains  one  modeling  example,  representing  a 
physical  layout  of  POIs  and  locations.  For  that  example,  the  file  may  include  several 
scenario  settings  which  differ,  for  example,  in  the  number  of  available  cameras,  or  in  the 
type  of  model  we  would  like  to  run.  The  structure  of  this  database  is  as  follows 
(Figure  1): 

Tables: 

LOG:  Locations 

POI:  Points  of  interest 

LOC  POI:  Attributes  for  locations  and  points  of  interest 

SCENARIO:  Different  scenarios  to  run,  and  associated  solutions  to  store,  for  the 
incumbent  “example”  (see  Section  D)  of  locations  and  POIs 

Queries: 

Delete  LOC:  Eliminates  all  records  from  LOC  table 

Delete  POI:  Eliminates  all  records  from  POI  table 

LOC  POI  CreateMatrix:  Creates  the  list  of  all  possible  combinations  of 
locations  and  POIs  to  ease  the  input  of  associated  probabilities 
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LOC_POI 


SCENARIO 


Queries 

ft 

LOC  POI  CreateMatrix 

■  * 

Delete.LOC 

Delete_POI 

Figure  1.  Database  tables  and  queries 


Relationships 


Figure  2.  Fields  for  the  database  tables,  and  relationships  among  tables 

Fields  in  each  of  the  above  tables  and  relationships  are  shown  in  Figure  2.  The 
tables  below  describe  these  fields  in  more  detail: 


Table:  LOC 


Name 

Type 

Default 

Description 

Node 

Text 

Location  code 

XCoor 

Double 

0.0 

X  coordinate 

YCoor 

Double 

0.0 

Y  coordinate 

FixedSelection 

Yes/No 

No 

If  "Yes"  and  ObeyFixed="Yes"  in  table  SCENARIO,  the  location  must  be  selected 

Selected 

Yes/No 

No 

Whether  or  not  the  location  was  selected  by  the  optimization  for  emplacement  of  a 
camera  (OUTPUT) 

Table:  POI 


Name 

Type 

Default 

Description 

Node 

Text 

POI  code 

XCoor 

Double 

0.0 

X  coordinate 

YCoor 

Double 

0.0 

Y  coordinate 

val 

Double 

1.0 

Value  of  the  POI 
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Table:  LOC  POI 


Name 

Type 

Default 

Description 

LOCnode 

Text 

Location  code 

POI node 

Text 

POI  code 

prob 

Double 

0.0 

Probability  of  detection  of  an  event  at  the  POI  from  the  location 

Selected 

Yes/No 

No 

Whether  or  not  the  POI  was  selected  by  the  optimization  to  be  surveyed  from  the 
location  (OUTPUT) 

Table:  SCENARIO 


Name 

Type 

Default 

Description 

index 

Lonq  Inteqer 

Scenario  index  (AUTOMATED) 

Run 

Yes/No 

Yes 

If  "Yes,’’  the  scenario  will  be  run  next  time  the  optimizer  is  executed 

MinMax 

Yes/No 

No 

If  "Yes,"  the  optimizer  solves  a  min-max  (MI-CL2)  problem.  If  no,  it 
solves  the  min  overall  average  value  (MIN-CL1)  problem. 

nCameras 

Lonq  Inteqer 

0 

Number  of  cameras  allowed 

nPOIsPerCamera 

Double 

2 

Number  of  POIs  each  camera  may  surveil  at  a  time 

ObeyFixed 

Yes/No 

No 

If  "Yes,"  the  fixed  selections  specified  in  table  LOC  must  be  followed 

Max  Time 

Long  Integer 

100 

Maximum  time  (seconds)  allowed  to  execute  the  run 

Max  Gap 

Double 

0.0 

Maximum  optimality  qap  allowed  (e.g.,  0.05  means  5%) 

Gap 

Double 

Actual  gap  achieved  after  the  optimization  (OUTPUT) 

E_Value 

Double 

Overall  expected  damage,  according  to  the  objective  of  model 
MIN-CL1  (OUTPUT) 

Max_Val 

Double 

Maximum  individual  damage,  according  to  the  objective  of  model  Ml- 
CL2  (but  already  corrected  for  the  use  of  logarithms)  (OUTPUT) 

CPU  time 

Double 

Computational  time  (seconds)  spent  in  the  optimization  (OUTPUT) 

3.  Other  Inputs 

Two  other  inputs  are  required  to  execute  a  problem:  The  database  filename  and 
the  solver  to  be  used.  These  are  specified  as  parameters  in  the  main  program 
(BETSSC.mos)  of  the  application,  which  is  the  point  from  where  the  XPRESS-MP 
application  is  executed. 

These  parameters  are  called  DBNAME  and  UseCPLEX,  respectively,  and  the 
excerpt  in  Figure  3  shows  an  example  of  how  these  can  be  set.  Specifically,  the 
highlighted  example  shows  that  the  database  to  be  used  is  under  the  “case\”  folder  (from 
the  incumbent  location  of  the  BETSS  C.mos  file)  and  the  filename  is  “Test_Large.mdb.” 
(Notice  the  extension  “.mdb”  should  be  omitted  when  specifying  the  file’s  name.) 
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Xpress-IVE  -  [BETSS_C.mos] 

0  File  Edit  View  Build  Debug 

Deploy  Modules  Wizards  Window  Optimizer 

Help 

□  B  Jt  Hn  r  .► 

■  ►  BO* A  "  ASDii  f 

m 

□  |=|  Hal  ^ 

•  °*  Si  k*  j*  ft.  6  1»E.. 

3  H  5 

DflTfl  var  obi 

S  1  H  3  ID  il/y  ID 

ctr  O-  I/O  t£.  Bou  e  g 

|  BETSS_C.mos  math_model.mos 

Solve. mos  outputs. mos  |  ^  ^  €  4!. 

#%[ 

i  m 

I***********************************  **********s»-****:>»-*****3l-:i»-**5»-***:»A 


Most  recent  entities  v 
Entities  ]  A->  Z  | 

(C:\JIEDDO\BETSS_ 


Model:  BETSS-C  Version  Linear  1.00 
Salmeron,  J.  ,  Wood ,  K. 

First  Version:  Javier  Salmeron ,  March  2010 
Last  Update:  Javier  Salmeron ,  September  2010 


l±j  ::  Parameters 
jj  Constants 
B  :•  Primitives 
B  •  scalars: 

B  I  ]  arrays: 

B  {}  sets: 

B  :•  Decision  Variables 
B  •  scalars: 


I 

i 


model  BETSS_C 

uses  "mmxprs",  "mmodbc",  "mmive",  "mmsystem" 


B  []  arrays: 

B  ::  Constraints 
B  •  scalars: 

B  1 1  arrays: 

B  ::  Subroutines 
B  procedures: 
jj  User-defined  Types 


parameters 


DBNAME= "cases// Test_Lacge" 

Us e_CPLEX= false 
'Use  CPLEX=true 


r 

VIS IBLE_COLOR=IVE_YELLOW 
POI_COLOR=IVE_RED 
LOCATION_COLOR=IVE_BLUE 
SELECTED  COLOR=IVE  MAGENTA 


Figure  3.  Specifying  the  database  name  and  whether  or  not  to  use  the  CPLEX  solver 

Similarly,  the  example  in  the  figure  indicates  the  CPLEX  solver  is  not  going  to  be 
used.  (Notice  the  “=true”  line  is  commented  out).  Thus,  all  selected  problems  from  the 
“case\Test_Large.mdb”  database  will  be  solved  using  the  XPRESS-MP’s  internal  solver. 

4.  Graphical  Input  and  Output  Environment 

Xpress-MP’s  embedded  graphical  displays  help  visualize  the  problem  and 
its  solution. 


For  example,  Figure  4  shows  a  snapshot  that  maps  out  POIs  and  candidate 
locations  for  cameras.  For  POIs  we  also  see  their  value.  By  clicking  on  the  “Visible” 
toggle,  we  would  see  a  series  of  lines  connecting  candidate  locations  with  those  POIs  that 
could  be  surveilled  (with  strictly  positive  probability  of  detection)  from  each  location. 

After  the  model  is  run,  the  “Selected”  toggle  shows  the  chosen  selected  locations 
for  the  case,  indicated  in  parenthesis  as  average  (“Avg”)  or  min-max  (“m-M”) 
optimization,  along  with  the  number  of  cameras  available  for  the  case.  The  “Sel. 
Visible”  (Selected  Visible)  toggle  displays  the  assigned  surveilled  POIs  from  the 
selected  locations. 
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Figure  4.  Preliminary  display  of  locations  (in  blue)  and  points  of  interest  (in  red) 

D.  EXAMPLES 

This  section  presents  results  for  two  hypothetical  situations  referred  to  as  “Small 
example”  and  “Large  example,”  respectively;  each  has  several  variants  or  “scenarios.” 

1.  Small  Example 

The  physical  layout  in  this  example  (Figure  4)  has  ten  potential  camera  locations 
and  eight  POIs.  Figure  5  shows  a  portion  of  the  example  with  “visibility”  links  activated, 
along  with  the  associated  probabilities  of  detection.  For  example,  the  probability  of 
detecting  POI  “14,”  if  surveilled  from  “L8,”  is  approximately  0.707. 
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Figure  5.  Small  Example  portion  with  line  of  sight  (in  yellow)  and 
detection  probabilities 

We  run  four  scenarios  for  this  example,  as  indicated  in  Figure  6.  The  setting  for 
the  first  scenario  (indexed  as  “328”  by  the  automated  counter)  seeks  to  minimize  overall 
expected  damage  (model  MIN-CL1).  We  have  three  cameras  available,  and  each  camera 
can  surveil  an  unlimited  number  of  POIs  simultaneously  (indicated  with  a  large  limit  of 
100  in  the  data).  The  second  scenario  (“329”)  is  the  same  as  “328”  except  that  the 
optimization  model  used  is  MIN-CL2;  that  is,  we  seek  to  minimize  the  maximum  damage 
at  an  individual  POT  Scenario  “338”  and  “339”  resemble  the  first  two  scenarios, 
respectively,  except  that  we  reduce  the  number  of  POIs  to  be  surveilled  from  any  one 
location  to  a  maximum  of  three.  All  scenarios  are  run  for  up  to  100  seconds  or  when  the 
optimality  gap  is  zero. 
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Figure  6.  Scenarios  for  Small  Example 
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Results  for  the  four  scenarios  are  summarized  in  Figure  7.  We  note  that  the  final 
gaps  are  zero  (i.e.,  the  solutions  presented  are  guaranteed  to  be  optimal)  and  the 
computational  times  are  under  one  second  in  all  cases. 

The  first  two  scenarios  show  that,  when  an  unlimited  number  of  POls  can  be 
surveilled,  both  the  overall-average  and  the  worst-case  optimal  solutions  are  similar.  The 
optimal  objective  for  M1N-CL1  yields  an  overall  expected  damage  of  11.15  (scenario 
index  “328”).  The  worst  POI  from  this  model  has  an  expected  damage  of  1.93. 
Coincidentally,  this  is  the  optimal  objective  function  value  obtained  when  Ml-CL  is  used 
for  that  goal  (scenario  index  “329”).  The  fact  that  the  converse  does  not  occur  (i.e.,  the 
overall  expected  damage  in  scenario  “329”  does  match  that  of  “328”)  is  a  consequence  of 
multiple  optimal  solutions  to  the  min-max  objective  in  MI-CL2.  Figure  8  shows  that  the 
only  difference  between  the  two  solutions  is  that  Ml-CL2  does  not  surveil  “14”  from 
“LI,”  nor  “15”  from  “L8,”  because  that  additional  surveillance  neither  improves  nor 
worsens  the  min-max  objective. 
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Figure  7.  Results  for  Small  Contract  scenarios 

The  last  two  scenarios,  which  limit  the  number  of  POIs  that  can  be  surveilled 
from  a  single  location,  have  reduced  detection  probabilities.  The  optimal  overall 
expected  damage  increases  to  20.59,  and  the  optimal  worst-case  individual  damage 
increases  to  3.40.  Figure  9  displays  these  two  scenarios. 
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Figure  8.  Graphical  solution  to  scenarios  “328”  (left)  and  “329”  (right) 


Figure  9.  Graphical  solution  to  scenarios  “338”  (left)  and  “339”  (right) 

2.  Large  Example 

This  setting  has  30  candidate  locations  to  surveil  100  POIs  (Figure  10). 
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Figure  10.  Large  Example  with  30  locations  and  100  POIs 

Figure  11  shows  the  scenarios.  Scenarios  “351”  through  “354”  are  solved  via 
MIN-CL1  with  5,  10,  15,  and  20  cameras  available,  respectively,  and  a  maximum  of  three 
POIs  surveilled  per  camera.  Scenario  “355”  is  the  same  as  scenario  “354”  (20  cameras 
available),  but  is  solved  with  MI-CL2,  instead.  Scenarios  “356”  though  “359”  explore  a 
20-camera  case  for  a  different  number  of  POIs  surveilled  per  camera.  (Notice  that  “358” 
is  the  same  scenario  as  “354.”) 
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Figure  1 1 .  Scenarios  for  the  Large  Example 

Results  for  all  scenarios  are  summarized  in  Figure  12.  As  expected,  there  is  a 
decrease  in  the  overall  damage  as  the  number  of  available  cameras  increases  (scenarios 
“351”  through  “354”).  We  can  improve  the  worst-case  individual  damage  (from  8.0  to 
4.0  in  this  case)  at  the  expense  of  increasing  the  overall  expected  damage  from  156.14  to 
207.86.  Note  that  the  solution  to  the  min-max  model  MI-CL2  takes  all  of  the  allotted 
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time  (five  minutes),  and  stops  with  an  optimality  gap  of  7.8%.  Finally,  we  observe  an 
improvement  in  the  solution,  as  the  number  of  POIs  that  can  be  surveilled  per 
location  increases. 
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Figure  12.  Results  for  Large  Example  scenarios 

Figures  13-17  present  graphical  displays  for  these  solutions  (but  hide  the  POI 
names  for  the  sake  of  clarity). 


Figure  13.  Graphical  solution  to  scenarios  “351”  (left)  and  “352”  (right) 
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Figure  14.  Graphical  solution  to  scenarios  “353”  (left)  and  “354”  (right) 


Figure  15.  Graphical  solution  to  scenario  “355” 
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Figure  16.  Graphical  solution  to  scenarios  “356”  (left)  and  “357”  (right) 


Figure  17.  Graphical  solution  to  scenarios  “358”  (left)  and  “359”  (right) 

E.  FUTURE  RESEARCH 

The  research  performed  in  this  project  can  be  extended  to  more  accurately  assess 
and  incorporate  the  “information  value”  of  a  collection  of  POIs  that  may  be  assigned  to 
one  or  more  camera  towers.  Our  current  implementation  assumes  a  simple  additive  or 
separable  value  function  that  ignores  “scheduling  issues.”  But,  a  camera  that  is  set  to 
surveil  a  given  collection  of  POIs  may  be  programmed  to  focus  on,  zoom  in  on,  and 
surveil  each  POI  for  a  given  amount  of  time  before  transitioning  to  another  POI.  The 
corresponding  surveillance  and  transition  times  affect  the  value  of  information  collected 
(for  example,  the  probability  that  an  IED  emplacement  is  detected),  and  should  be  part  of 
the  optimization  process.  A  related  problem  is  how  those  settings  may  affect  the 
efficiency  of  multiple  cameras  surveilling  a  single  POI  “A.”  For  example,  cameras  Cl 
and  C2  might  have  line  of  sight  to  a  given  POI  “A,”  but  camera  Cl  could  spend  its  time 
more  fruitfully  observing  other  POIs;  thus,  only  camera  C2  should  observe  POI  “A,”  or 
Cl  should  be  scheduled  to  scan  this  POI  only  occasionally. 
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Secondly,  our  current  models  also  assume  constant  conditions.  However, 
day/night-  or  weather-related  conditions  may  affect  the  probabilities  of  detection  and 
could  influence  the  optimal  location  of  surveillance  systems.  In  addition,  we  currently 
assume  that  the  surveillance  systems  are  fixed,  i.e.,  once  deployed,  they  cannot  be 
relocated.  By  incorporating  the  dynamics  of  other  surveillance  systems  (such  as  UAVs 
or  the  Eagle  Eye  mobile  observation  tower)  in  our  analysis,  it  may  be  possible  to  provide 
better  answers  to  problems  with  changing  conditions. 

Future  research  may  also  perform  simulations  to:  (1)  perform  “what  if’  analysis 
for  some  key  inputs  which  may  be  difficult  to  estimate  by  planners,  such  as  POI  values; 
and  (2)  analyze  recommended  locations  under  several  potential  terrorist  behaviors.  For 
example,  a  “greedy”  (or  risk-averse)  behavior  may  be  simulated  as  a  terrorist  attempting 
to  emplace  an  IED  at  a  high-value  POI,  which  is  being  heavily  surveilled.  Other 
behaviors,  from  purely  deterministic  to  random  (including  the  selection  of  POI  and  time 
of  day),  can  be  integrated  and  may  help  assess,  enhance,  and  validate  the 
recommendations  provided  by  the  models  described  in  this  report. 
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